NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/18520

Internet Message Format | 1996-08-05 | 6.6 KB

Path: sky.net!not-for-mail
From: [e-mail] (Eric Williams)
Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
Subject: Re: Will Java kill C++?
Date: 21 Apr 1996 00:32:24 -0500
Organization: SkyNET Online
Message-ID: <4lch98$[e-mail]>
References: <4ks0c8$[e-mail]> <[e-mail]> <4ksfdr$[e-mail]> <[e-mail]>
NNTP-Posting-Host: solar.sky.net

Andrew Koenig <[e-mail]> wrote:
>In article <4ksfdr$[e-mail]> [e-mail] (Peter van der Linden) writes:
>
>> Andrew Koenig <[e-mail]> wrote:
>> > why aren't you agitating for a name-mangling standard in C?
>> > Name mangling is a potential problem there too.
>
>> It may be a potential problem, but name mangling isn't an actual problem in C.
>> Names either don't get mangled, or everyone mangles them the same trivial way.
>
>That's actually not quite true.  For example, some C compilers put an
>underscore at the beginning of external names, and others don't.  I imagine
>there are other possibilities too.


There's one essential problem you're not discussing..... if you violate
a platform's abi by creating your own naming standard for C symbols (or
violate something else in the abi), how will you market your product?
The marketplace has not tolerated this sort of deviation well, and you
will find non-conforming C compilers to be a hard sell indeed....  The
marketplace seems to accept de-facto standards where no official
standards exist.  I'd even go a step further to state that on most
platforms, the hardware/OS *vendor* is expected to provide the de-facto
standards.

I think these kind of de-facto standards are very powerful.  For example,
gcc has been accepted on unix platforms to a much greater degree than g++
partly because gcc is mostly compatible with the standards and conventions
on each platform --- g++ remains largely incompatible with the "standard"
(i.e., vendor-supplied) C++ compiler on each platform.


I realize that it's not just name-mangling conventions that cause
incompatibility between C++ compilers on the same platform.....
just thinking about object layouts involving virtual base classes is
enough to give me fits and starts.  But I think the answer to why C++
compilers remain incompatible has more of an explanation than "it's too
hard to express the concepts".  There are several reasons why C++
compilers are incompatible:

  * Complexity - The inherent complexity of C++ has led to a number
    of truly creative solutions to the problems in the C++ compiler
    design space.  Unfortunately, once these investments were made,
    it became very difficult to change.  If you've already got a
    solution, why would you want to re-engineer your compiler ---
    the thing was damn hard to get right in the first place.

  * Complexity (again) - So much energy was expended in fighting
    about complex C++ features during ANSI standardization that nobody
    wanted or had enough energy to fight about "compatibility".
    Plus, everyone knew that it would be a lost cause anyway ---
    there would be too much vendor opposition to get it through
    the committee.

  * Competition - If you standardize your implementation, you open
    the doors for competition.  Why would you want to do that?
    Cross-platform compiler vendors have had no chance in the C++
    market.  For an example, look at CenterLine:  when everyone was
    using cfront, they had a market..... but now that each vendor
    is implementing a different solution, they can't even keep
    a debugger up to date across platforms, much less the compiler.

  * It's *my* solution - We don't like to admit it, but as engineers
    we *love* re-inventing the wheel in different ways.  If the
    business constraints let us get creative, we will --- we'll
    create the best solution we can think of, and then fight tooth
    and nail if someone suggests that it's not an optimal solution.

If the major C++ vendors had thought that link-compatibility
was a major issue, the technical details would have been worked
out --- even though it's a non-trivial task.


>> Let's try and face up to the deficiencies of C++.  Not say "well C might
>> be just as bad".  When we admit the deficiencies of C++, we can start to
>> look for something better.  No programming language is perfect, let's just
>> try to make them monotonically better.
>
>I completely agree with you.  But that is no excuse for inventing deficiencies
>that do not exist.

Name-mangling can still be considered a hack, in the sense that each
vendor worked out their own solution.  That's the essential point of
this whole discussion --- each C++ vendor's solution is different.

My personal intuition says that compatibility is one of the major
factors behind the conversion of droves of C++ afficianadios to Java,
right behind "reduced complexity".  There aren't 27 different solutions
to template instantiation any longer --- in fact, templates themselves
are no more.

C++ was intially a "cool" language to learn..... then developers started
to use it in large projects, and began to see it as "complex"..... and
now many feel that the complexity is unmanageable.  You almost have to
have a compiler expert on every project just to work through compiler
differences and to diagnose compiler bugs.  Java eliminates a good deal
of this complexity, and that's why experienced C++ programmers are
jumping ship --- it is easier to teach your co-workers how to use
Java than it is to teach them how to use C++.  And you get a bigger bang
for your buck..... e.g., you can *actually* think about writing multi-
threaded programs.  By eliminating much of the complexity and platform
differences, it is as if developers have more room in their brains to
store the advanced concepts, such as exception handling and concurrency
control.

With Java, it won't even matter what platform you use for development....
your applets/applications should work the same on every platform.  (Ok,
that is a little over-optimistic, but it's certainly better than creating
a separate three-month project just to port your application once it has
been shipped on a reference platform.)


I will be very interested to see how things progress for Java if/when
it undergoes standardization....  And even before that, how will the
market react to implementations that materially diverge from the
specified standards and unspecified conventions of Java?  The market
is the driving force here --- if the market wants features over
compatibility, then they will get it.  If compatibility remains a high
priority, then incompatible implementations will not survive.


-eric
-----
[e-mail]